CSDV3017  ·  DEVOPS  ·  SCHOOL OF COMPUTER SCIENCE, UPES

Infrastructure as Code,
CD & Jenkins Pipelines

Lecture 11 — from manually configuring servers to declaring infrastructure in code, automating the path to production with Continuous Delivery, and building industrial-grade pipelines with Jenkins.

InstructorDr. Mohsin Furkh Dar
SessionWeek 4 · Tue, 30 Jun 2026
Time12:00 – 13:00
UnitUnit IV
I
II
III
IV
V
VI
VII
WHERE WE LEFT OFF

Recap & today's agenda

Lecture 10 · Done

Principles, VCS & CI

  • 4 core DevOps principles (Systems Thinking, Feedback, Experimentation, Automation)
  • SVN (centralized) → Git (distributed) evolution
  • Gitflow branching: main, develop, feature, release, hotfix
  • CI with GitHub Actions — YAML workflows, Workflow → Job → Step
Lecture 11 · Today

IaC, CD & Jenkins

  • Infrastructure as Code — what it is, why it matters, key tools
  • Continuous Delivery vs Continuous Deployment
  • Continuous Monitoring — closing the feedback loop
  • Jenkins — the OG of CI/CD pipelines, Jenkinsfile deep dive
THE PROBLEM

Why manual infrastructure is a nightmare

"The server was configured by hand 3 years ago by someone who has since left the company. Nobody knows what's on it. Nobody dares touch it." — the "Snowflake Server" anti-pattern

Problem 01

Snowflakes

Every server is unique. Subtle differences cause "works in staging, breaks in production" bugs that take days to diagnose.

Problem 02

Configuration Drift

Over time, manual patches and hotfixes cause servers to diverge from their original state. No two servers in the "same" cluster are actually identical.

Problem 03

Disaster Recovery

If a manually configured server dies, rebuilding it from scratch takes weeks of guesswork. There is no "blueprint" to follow.

THE SOLUTION

Infrastructure as Code (IaC)

Definition

What is Infrastructure as Code?

IaC is the practice of managing and provisioning computing infrastructure through machine-readable definition files, rather than through manual hardware configuration or interactive tools. Infrastructure is treated exactly like application source code — versioned in Git, reviewed in Pull Requests, and tested automatically.

Key Benefits

Why IaC matters

  • Reproducibility: Spin up identical environments in minutes
  • Version Control: Every infra change is tracked in Git
  • Self-Documenting: The code IS the documentation
  • Scalability: Deploy 1 or 1,000 servers with the same file
  • Auditability: Git blame shows who changed what and when
Two Approaches

Declarative vs Imperative

  • Declarative: "I want 3 servers with 8GB RAM running Nginx." The tool figures out how. (Terraform, Kubernetes YAML)
  • Imperative: "Step 1: Create a VM. Step 2: Install Nginx. Step 3: Open port 80." You tell the tool exactly what to do. (Ansible playbooks, shell scripts)
IaC TOOLBOX

The major IaC tools

Tool Type Primary Use Language
Terraform Declarative Provisioning cloud resources (AWS VPCs, EC2, S3, Azure VMs). Multi-cloud. HCL (.tf files)
Ansible Imperative (Procedural) Configuration management — install software, manage files, run commands on existing servers. YAML (.yml playbooks)
Puppet Declarative Configuration management for large fleets; agent-based enforcement of desired state. Puppet DSL (.pp manifests)
CloudFormation Declarative AWS-only provisioning. Deep integration with AWS services. JSON / YAML
Docker / K8s Declarative Container images (Dockerfile) and orchestration (K8s YAML manifests). Dockerfile / YAML

Key distinction: Terraform provisions the infrastructure (creates the servers). Ansible/Puppet configure what runs on them. In practice, teams use Terraform + Ansible together.

HANDS-ON

Terraform in 30 seconds

# main.tf — Provision an AWS EC2 instance

provider "aws" {
  region = "ap-south-1"   # Mumbai
}

resource "aws_instance" "web_server" {
  ami = "ami-0c55b159cbfafe1f0"
  instance_type = "t2.micro"

  tags = {
    Name = "DevOps-Demo-Server"
  }
}
Step 1

terraform init

Downloads the AWS provider plugin.

Step 2

terraform plan

Dry run — shows what WILL be created without doing it.

Step 3

terraform apply

Actually creates the EC2 instance in AWS. Type "yes" to confirm.

CONTINUOUS DELIVERY

Continuous Delivery vs Deployment

Continuous Delivery

Always Ready to Ship

  • Every code change passes through automated build, test, and staging
  • The artifact is production-ready at all times
  • A human approves the final deployment to production (manual gate)
  • Used by: banks, healthcare, government — regulated industries
Continuous Deployment

Fully Automated to Production

  • Same pipeline as Delivery, but the manual gate is removed
  • Every commit that passes all tests is automatically deployed to production
  • No human approval — the pipeline is the gatekeeper
  • Used by: Netflix, Facebook, Etsy — dozens of deploys per day
Code
→
Build
→
Unit Tests
→
Integration Tests
→
Staging
→
Manual Gate?
→
Production
DEPLOYMENT PATTERNS

How to deploy safely

Strategy 01

Blue-Green Deployment

Run two identical production environments. "Blue" is live. Deploy new version to "Green." Switch the load balancer to Green. If it fails, switch back to Blue instantly.

⚡ Zero-downtime rollback.

Strategy 02

Canary Deployment

Route 5% of real user traffic to the new version. Monitor error rates and latency. If healthy, gradually ramp to 25% → 50% → 100%. If unhealthy, abort and roll back.

🐦 Named after canaries in coal mines.

Strategy 03

Rolling Update

Replace instances one at a time. Server 1 is updated while 2-10 handle traffic. Then Server 2, etc. Used by Kubernetes by default.

🔄 No extra infrastructure needed.

Anti-Pattern

Big Bang Deployment

Take the entire system offline, deploy the new version, pray, and bring it back up. High risk, maximum downtime, zero rollback path.

🚫 Avoid in modern DevOps.

CLOSING THE LOOP

Continuous Monitoring

Definition

What is Continuous Monitoring?

The practice of automatically and constantly observing infrastructure, applications, and security posture in real-time. It generates the feedback data that flows back from the "Operate/Monitor" phase into the "Plan" phase, completing the DevOps infinity loop.

Layer 1

Infrastructure

  • CPU, Memory, Disk, Network
  • Container health (K8s pod restarts)
  • Tools: Prometheus, Grafana, Datadog
Layer 2

Application (APM)

  • Response times, Error rates, Throughput
  • Database query profiling
  • Tools: New Relic, Dynatrace, OpenTelemetry
Layer 3

Logs & Security

  • Centralized log aggregation (ELK/EFK)
  • Security event monitoring (SIEM)
  • Tools: Splunk, Elastic, PagerDuty
KEY METRICS

The 4 DORA metrics

The DevOps Research and Assessment (DORA) team at Google identified four key metrics that predict software delivery performance. Elite teams score high on all four.

DF
Deployment Frequency

How often code is deployed to production. Elite: multiple times/day.

LT
Lead Time for Changes

Time from commit to production. Elite: less than 1 hour.

CFR
Change Failure Rate

% of deployments that cause a failure. Elite: 0-15%.

MTTR
Mean Time to Recovery

Time to restore service after a failure. Elite: less than 1 hour.

JENKINS

Jenkins — the original CI/CD engine

Overview

What is Jenkins?

  • Open-source automation server, started in 2004 as "Hudson"
  • Self-hosted (runs on your own servers, not in the cloud like GitHub Actions)
  • 1,800+ plugins for every conceivable integration
  • Still the most widely used CI/CD tool in enterprises
  • Written in Java; runs on any OS with a JVM
Architecture

Controller + Agent Model

  • Controller (Master): Manages the UI, schedules builds, distributes work
  • Agents (Slaves): Worker machines that actually execute the build steps
  • Agents can be VMs, Docker containers, or Kubernetes pods
  • This model scales horizontally — add more agents as workload grows
COMPARISON

Jenkins vs GitHub Actions

Feature Jenkins GitHub Actions
Hosting Self-hosted (you manage the server) Cloud-hosted (GitHub manages runners)
Setup Install Java, Jenkins, configure manually Zero setup — add a YAML file to your repo
Config Jenkinsfile (Groovy DSL) .github/workflows/*.yml (YAML)
Plugins 1,800+ (massive ecosystem, but some are outdated) Marketplace Actions (modern, community-driven)
Best For Complex enterprise pipelines with many integrations GitHub-native projects wanting fast, simple CI/CD
Cost Free software, but you pay for server infrastructure Free tier (2,000 min/month); pay-per-minute after
HANDS-ON

A Declarative Jenkinsfile

// Jenkinsfile (Declarative Pipeline)

pipeline {
  agent any

  stages {
    stage('Build') {
      steps {
        sh 'mvn clean compile'
      }
    }
    stage('Test') {
      steps {
        sh 'mvn test'
      }
    }
    stage('Deploy') {
      when { branch 'main' }
      steps {
        sh './deploy.sh production'
      }
    }
  }
  post {
    failure { mail to: 'team@example.com', subject: 'Build Failed!' }
  }
}

Key concepts: pipeline wraps everything. agent any means run on any available worker. stages run sequentially. The when directive ensures Deploy only runs on the main branch. post handles success/failure notifications.

PIPELINE ANATOMY

A real-world Jenkins pipeline

Checkout
→
Build
→
Unit Test
→
SAST Scan
→
Docker Build
→
Push to Registry
→
Deploy Staging
→
Deploy Prod
Left Side (CI)

Build & Verify

  • Checkout: Clone code from Git
  • Build: Compile source code (mvn compile, npm build)
  • Unit Test: Run automated tests
  • SAST Scan: Static security analysis (SonarQube)
Right Side (CD)

Package & Deploy

  • Docker Build: Package app into a container image
  • Push to Registry: Upload image to Docker Hub / ECR
  • Deploy Staging: Deploy to a staging environment for E2E tests
  • Deploy Prod: Deploy to production (manual or auto gate)
WRAP-UP

Summary & what's next

Lecture 11 · Key Takeaways

What you should remember

  • IaC: Infrastructure defined in code files (Terraform, Ansible), versioned in Git, reproducible and auditable
  • Declarative vs Imperative: "What I want" (Terraform) vs "How to do it" (Ansible)
  • CD: Continuous Delivery = manual gate before prod; Continuous Deployment = fully automated
  • Deployment Strategies: Blue-Green (instant rollback), Canary (gradual ramp), Rolling (one-at-a-time)
  • Monitoring: Infrastructure + APM + Logs; DORA metrics (DF, LT, CFR, MTTR)
  • Jenkins: Self-hosted CI/CD; Controller + Agent architecture; Declarative Jenkinsfile (pipeline → stages → steps)
Next Lecture · Lecture 12

Tue, 30 Jun 2026 · 14:00–15:00 · Unit IV

Metrics tools; DevOps lifecycle; Digital transformation & role of DevOps.

Before next class

Quick prep

Think about which DORA metric your future team would struggle with most and why. We'll discuss digital transformation through the lens of these metrics.

CSDV3017 · DEVOPS
SHEET 01/15